home *** CD-ROM | disk | FTP | other *** search
/ Chip 2000 May / Chip_2000-05_cd1.bin / sharewar / FFE / GRAPH.SWG / 0048_JPEG DIB Encoding Format.pas < prev    next >
Encoding:
Pascal/Delphi Source File  |  1997-05-11  |  34.6 KB  |  816 lines
  1. Microsoft Windows Bitmap Format
  2.  
  3. (c) 1993 Microsoft Corporation. All rights reserved.
  4.  
  5.  
  6. Multimedia Technical Note: JPEG DIB 
  7. Format
  8.  
  9. Created: May 26, 1993
  10.  
  11. Goals for this DIB Format Extension
  12.  
  13. The purpose of this specification is twofold:
  14.  
  15. 1.        To define a standard DIB extension for storing JPEG-encoded 
  16. still images.
  17.  
  18. 2.        To define a standard DIB extension for storing JPEG-encoded 
  19. motion images.
  20.  
  21. A standard DIB extension is one in which the data format is clearly
  22. defined so that any codec that claims to understand the standard will
  23. be able to process the image data correctly. In addition, the image
  24. data created by any codec must be readable by any other codec. In
  25. other words, it must conform to the standard.
  26.  
  27. These standards are extensions to the standard DIB format defined by
  28. Microsoftr Windows version 3.0 and extended by the technical note
  29. entitled "DIB Format Extensions."
  30.  
  31. This standard will provide:
  32.  
  33. *        Immediate support for partial implementation of the full scope of
  34. JPEG Baseline Sequential DCT process as defined in ISO 10918 for SOF0
  35. (marker Code 0xFFC0). The implemented subset of the full scope shall
  36. maximize cross-platform interchange between the known universe of
  37. existing JPEG codecs.
  38.  
  39. *        Provision for transparent (or nearly so) implementation of the
  40. full scope of JPEG Baseline Sequential DCT process as defined in ISO
  41. 10918 for SOF0 (marker Code 0xFFC0).
  42.  
  43. *        Provision for subsequent inclusion of additional non-hierarchical
  44. JPEG processes on a singular and individual basis. The additional
  45. JPEG processes identified by JPEG Markers SOF1, SOF2, SOF3, SOF9, 
  46. SOF10, and SOF11 shall be capable of being implemented in whole or in
  47. part by codecs with no constraint on the number or combination of
  48. processes implemented. Provision for hierarchical processes is deemed
  49. inappropriate to the DIB context.
  50.  
  51. *        Maximal conformance to existing implications of the 
  52. BITMAPINFOHEADER structure and its use at application level and
  53. system level. Adaptive redefinition of the BITMAPINFOHEADER shall
  54. provide that members of the basic BITMAPINFOHEADER shall be
  55. identically defined as the preliminary (and primary) members of each
  56. re-definition of the BITMAPINFOHEADER. As a result, a pointer to a
  57. re-defined BITMAPINFOHEADER structure shall always be capable of
  58. being recast as a pointer to the basic BITMAPINFOHEADER from which it
  59. is derived.
  60.  
  61. *        Consideration of the usage of the revised BITMAPINFOHEADER within
  62. enclosing structures of type BITMAPINFO, or analogous substitutes for
  63. BITMAPINFO.
  64.  
  65. *        Define JPEG DIBs in a manner "suitable" for AVI incorporation,
  66. but unconstrained by AVI specific usage. A standalone JPEG DIB image
  67. file shall not include conventions adopted solely for the convenience
  68. of AVI file construction. The off-line process of creating AVI files 
  69. should not bring AVI peculiar design requirements into the arena of
  70. still image files.
  71.  
  72. It is assumed that the reader is familiar with JPEG as defined in the
  73. ISO 10918 document. For additional information on JPEG see the ISO
  74. 10918 document.  For additional information about RIFF files, see the
  75. Microsoft Windows Software Development Kit (SDK) Multimedia 
  76. Programmer's Guide and Multimedia Programmer's Reference.  For
  77. additional information on installable compressors and decompressors,
  78. see the "Video Compression/Decompression Drivers" technical note from
  79. Microsoft.
  80.  
  81. General Specifications
  82.  
  83. This specification will define two standards for use in Windows:
  84.  
  85. 1.        JPEG still-image format
  86. 2.        JPEG motion format (a.k.a. motion-JPEG)
  87.  
  88. Type 1: Still Image JPEG
  89.  
  90. All JPEG DIB still image formats (e.g., DIB files) shall embed a 
  91. complete "Interchange Format" JPEG data stream as a contiguous whole.
  92. This provision shall eliminate inadvertent introduction of platform-,
  93. system-, or application-specific conditions that may cause some
  94. JPEG-compliant codecs to be incapable of processing the embedded JPEG
  95. data of a DIB. Provision for indexed access to tables and other data
  96. within the JPEG portion of a DIB shall be accommodated solely by the
  97. introduction of new offset and length members in the body of the
  98. revised BITMAPINFOHEADER structure (none are yet defined). This
  99. provision permits any application or codec to construct a JPEG DIB
  100. file simply by prepending the defined structures to JPEG data, then
  101. perform a single pass through the JPEG data to calculate and set the
  102. associated offset and length members which correlate to JPEG data
  103. items.
  104.  
  105. Type 2: Motion JPEG
  106.  
  107. Motion JPEG DIBs shall accommodate interchange formats that satisfy
  108. the "General sequential and progressive syntax" (ISO 10918 Part 1,
  109. Annex B, Para. B.2). A set of images of this type with compatible
  110. parameters can be placed in an AVI file to describe a motion
  111. sequence. Frame headers for these DIBs shall be limited to those
  112. specified in Para B.2.2 of the cited Annex B. These types are SOF0,
  113. SOF1, SOF2, SOF3, SOF9, SOF10, and SOF11. Of the types accommodated,
  114. this specification provides implementation only for the Baseline 
  115. Sequential DCT.
  116.  
  117. BITMAPINFOHEADER for JPEG
  118.  
  119.  
  120.  
  121. typedef struct tagEXBMINFOHEADER {
  122.      BITMAPINFOHEADER     bmi;
  123.      /* extended BITMAPINFOHEADER fields */
  124.      DWORD  biExtDataOffset;
  125.      /* Other stuff will go here */
  126.  
  127.      /* Format-specific information */
  128.      /* biExtDataOffset points here */
  129. } EXBMINFOHEADER;
  130.  
  131. typedef struct tagJPEGINFOHEADER {
  132.      /* compress-specific fields */
  133.      DWORD  JPEGSize;
  134.      DWORD  JPEGProcess;
  135.  
  136.      /* Process specific fields */
  137.      DWORD  JPEGColorSpaceID;
  138.      DWORD  JPEGBitsPerSample;
  139.  
  140.      DWORD  JPEGHSubSampling;
  141.      DWORD  JPEGVSubSampling;
  142. } JPEGINFOHEADER
  143.  
  144. Field        Description
  145.  
  146. Standard BITMAPINFOHEADER fields        
  147.  
  148.  
  149. These fields are valid for all DIBs, regardless of compression format.
  150.  
  151.  
  152. biSize        Size of entire set of structures for header data. Image offset
  153. in DIB file or '"packed" DIB is: biSize + biColorUsed*sizeof
  154. (RGBQUAD)
  155.  
  156. biWidth        Width of decompressed image in pixels.
  157.  
  158. biHeight        Height of decompressed image in pixels.
  159.  
  160. biPlanes        1
  161.  
  162. biBitCount        24 for RGB or YCbCr, 8 for Y only images (8 bit mono). The
  163. values and their meanings are as follows.1: The bitmap is monochrome,
  164. and the color table contains two entries. Each bit in the bitmap
  165. array represents a pixel. If the bit is clear, the pixel is displayed
  166. with the color of the first entry in the color table. If the bit is
  167. set, the pixel has the color of the second entry in the table.4: The
  168. bitmap has a maximum of 16 colors. Each pixel in the bitmap is
  169. represented by a four-bit index into the color table. For example,
  170. the first byte in the (uncompressed) bitmap is 0x1F and the byte
  171. represents two pixels. The first pixel contains the color in the
  172. second table entry, and the second pixel contains the color in the
  173. 16th color table entry.8: The bitmap has a maximum of 256 colors.
  174. Each pixel in the (uncompressed) bitmap is represented by a
  175. byte-sized index into the color table. For example, if the first byte
  176. in the (uncompressed) bitmap is 0x1F, then the first pixel has the
  177. color of the thirty-second table entry.24: The bitmap has a maximum
  178. of 224 colors. The biClrUsed and biClrImportant fields can optionally
  179. be used (by setting biClrUsed to non-zero) to store an optimized
  180. palette for the image.N (for N > 8): The bitmap has a maximum of 2N
  181. colors. The biClrUsed and biClrImportant fields can optionally be used
  182. (by setting biClrUsed to non-zero) to store an optimized palette for
  183. the image.
  184.  
  185. biCompression        Specifies the type of compression for a compressed
  186. bitmap. See the technical note entitled "DIB Format Extensions" for a
  187. complete list. Values and their meanings are as 
  188. follows.mmioFOURCC('J','P','E','G'): Still image JPEG
  189. DIB.mmioFOURCC('M','J','P','G'): Motion image JPEG DIB.
  190.  
  191. biSizeImage        Specifies the size of the compressed image data in bytes.
  192. For JPEG data, this is the length of the data including the EOI
  193. marker.
  194.  
  195. biXPelsPerMeter        0. Specifies the horizontal resolution in pixels per
  196. meter of the target device for the bitmap. An application can use
  197. this value to select from a resource group that best matches the 
  198. characteristics of the current device.
  199.  
  200. biYPelsPerMeter        0. Specifies the vertical resolution in pixels per
  201. meter of the target device for the bitmap.
  202.  
  203. biClrUsed        0 to 256. Specifies the number of color values in the
  204. color table actually used by the bitmap. See also the biBitCount
  205. field description.
  206.  
  207. biClrImportant        0. Specifies the number of color indexes that are
  208. considered important for displaying the bitmap. If this value is 0
  209. and biClrUsed is non-zero, all used colors are important.
  210.  
  211.  
  212. Extended BITMAPINFOHEADER fields        
  213.  
  214.  
  215. biExtDataOffset        Specifies the offset to the start of the JPEG-specific
  216. data. This field allows for an expanding BITMAPINFOHEADER structure.
  217.  
  218.  
  219. JPEG DIB Specific fields        
  220.  
  221.  
  222.         These fields start at the offset specified by biExtDataOffset.
  223.  
  224. JPEGSize        Size of the JPEG DIB specific fields. This field allows
  225. for expanding the JPEG DIB specific fields.
  226.  
  227. JPEGProcess        Specifies the various format types. In this extension,
  228. only 0 (Baseline DCT sequential) is allowed.
  229.  
  230.  
  231. Process Specific fields        
  232.  
  233.  
  234. JPEGColorSpaceID        Specifies the color space used for the compressed
  235. JPEG data.JPEG_Y. The Y only component of YCbCr, as described below.
  236. Implies 1 component.JPEG_YCbCr. YCbCr as defined by CCIR 601 (256
  237. levels). The RGB components calculated by linear conversion from YC C
  238. shall not be gamma corrected (gamma = 1.0). Implies 3 components.
  239. This is the only option defined for motion JPEG images.JPEG_RGB. 24
  240. bit RGB. (3 components).
  241.  
  242. JPEGBitsPerSample        Specifies the number of bits per sample per
  243. component for the defined color space. For this extension, this value
  244. will be 8. The subsequent frame header shall have its sample 
  245. precision parameter set to 8.
  246.  
  247.  
  248. JPEGHSubSampling        Specifies the horizontal sampling factors used for
  249. the chrominance components of a YCbCr image. Applicable only to
  250. images with JPEGColorSpaceID == 2 (YCbCr). Specifies the horizontal
  251. sampling factor for the chrominance components (jointly) with respect
  252. to the luminance component. Non-zero values must correlate to the
  253. "Hi" values for both chrominance components in the JPEG frame header
  254. (see ISO 10918). The values and their meanings are as follows.0:
  255. Subsampling is not- applicable (JPEGColorSpaceID != 2).1: For every
  256. luminance sample in the horizontal dimension, the chrominance
  257. components are sampled in a 1:1 ratio.2: For every luminance sample in
  258. the horizontal dimension, the chrominance components are sampled in a
  259. 1:2 ratio, with chrominance samples (Cb and Cr separately) sampled at
  260. half the horizontal spatial resolution as for luminance.4: For every
  261. luminance sample in the horizontal dimension, the chrominance
  262. components are sampled in a 1:4 ratio, with chrominance samples (Cb
  263. and Cr separately) sampled at one-fourth the horizontal spatial
  264. resolution as for luminance.
  265.  
  266. JPEGVSubSampling        Applicable only to images with JPEGColorSpaceID =2
  267. (YCbCr). Specifies the vertical sampling factor for the chrominance
  268. components (jointly) with respect to the luminance component.
  269. Non-zero values must correlate to the "Vi" values for both chrominance
  270. components in the JPEG frame header (see ISO 10918). The values and
  271. their meanings are as follows.0: Subsampling is not- applicable
  272. (JPEGColorSpaceID != 2).1: For every luminance sample in the vertical
  273. dimension, the chrominance components are sampled in a 1:1 ratio.2:
  274. For every luminance sample in the vertical dimension, the chrominance
  275. components are sampled in a 1:2 ratio, with chrominance samples (Cb
  276. and Cr separately) sampled at half the vertical spatial resolution as
  277. for luminance.4: For every luminance sample in the vertical
  278. dimension, the chrominance components are sampled in a 1:4 ratio, with
  279. chrominance samples (Cb and Cr separately) sampled at one-fourth the
  280. vertical spatial resolution as for luminance.
  281.  
  282. This specification affirms that the member biSize of structure 
  283. type BITMAPINFOHEADER and all JPEG derivative 
  284. redefinitions of BITMAPINFOHEADER shall be identically 
  285. defined. The member biSize shall always contain the count of 
  286. all bytes within the header information.
  287. This specification affirms that the structure format and member 
  288. definition shall be correlated uniquely to the value of the 
  289. member biCompression. Further additions to the structure 
  290. definition shall not break any previous definitions, just as this 
  291. definition's use of the predefined fields (biSize especially) does 
  292. not break the BITMAPINFOHEADER definition. By virtue of this 
  293. provision, any application or system function given a pointer to 
  294. a BITMAPINFOHEADER structure (or derivative thereof) shall 
  295. be capable of determining the appropriate "recast" typedef by 
  296. examination of biCompression alone, with biSize serving only 
  297. as a cross-check. biSize can increase (but it should not 
  298. decrease) from the known definition.
  299.  
  300. This specification affirms that each redefinition of BITMAPINFOHEADER
  301. for any value of biCompression shall contain the identical initial
  302. members as defined for BITMAPINFOHEADER under Windows 3.1. This shall
  303. apply equally to future redefinition of BITMAPINFOHEADER for those 
  304. biCompression values already incorporated (e.g., BI_RGB, BI_RLE8, and
  305. BI_RLE4).
  306.  
  307. The offset to the start of the compression specific data is specified
  308. by the biExtDataOffset field. This is the offset from the beginning
  309. of the BITMAPINFOHEADER for JPEG structure.
  310.  
  311. For JPEG DIB compression structure, the second field is always the
  312. JPEG process used to compress the image. The process-specific fields
  313. may change depending on the process ID in the JPEGProcess field.
  314.  
  315. Image Data
  316.  
  317. Image data should not contain any thumbnail or other optional data as
  318. this will greatly increase the size of the image data. If thumbnail,
  319. copyright, creator, etc. information is desired, the appropriate RIFF
  320. chunks should be used to store this data (see the RDIB definition in
  321. the RIFF references).  The inclusion of optional data (e.g.,
  322. comments, application-specific data, etc.) is strongly discouraged as
  323. this will greatly increase the size of the image data.
  324.  
  325. Type 1: Still-image JPEG
  326.  
  327. Complete JPEG interchange format stream from SOI-EOI including all
  328. tables and compressed data IAW ISO 10918 para 3.9.1"Interchange
  329. Format". The size of the data shall be defined by the field
  330. biSizeImage in the BITMAPINFOHEADER for JPEG structure.
  331.  
  332. Type 2: Motion JPEG
  333.  
  334. This DIB type contains incomplete JPEG data (abbreviated format per
  335. ISO 10918) and is not intended for stand-alone single image frame
  336. disk files. It may be used within RIFF files and other contexts where
  337. it is appropriate to:
  338.  
  339. *        Decode an image without supplying the associated JPEG Huffman
  340. tables. This presumes the codec has been properly pre-initialized
  341. prior to image decode.
  342.  
  343. *        Request encoder output of compressed image data absent embedded
  344. Huffman Tables.
  345.  
  346. All motion JPEG data will use YCrCb encoding.  In an AVI sequence,
  347. all JPEG frames will be key frames as this ensures that within the
  348. AVI and Video for Windows architecture all frames will be directly
  349. and independently addressable.
  350.  
  351. For optimal size and speed during playback of an AVI file, the 
  352. Huffman data used by motion JPEG will be fixed and defined by this
  353. document. This will make the individual frames of every motion
  354. sequence smaller and more efficient to play back. Also, because all
  355. sequences of motion images use the same Huffman data and color space,
  356. it is much more likely that motion data can be directly exchanged
  357. without re-compression. A definition of the Huffman data will be 
  358. provided in MMREG.H (which is listed at the end of this document) as
  359. a byte string which can be concatenated onto the start of a motion
  360. JPEG image to form a valid still JPEG image.
  361.  
  362.  
  363.  
  364. MJPGDHTSeg = { X'FF', DHT, length, JPEG Huffman table parameters }
  365.  
  366. Q-table data is present and may vary in every frame of a motion
  367. sequence to permit control over the bandwidth of sequences that
  368. contain bursts of frames of varying levels of complexity. The restart
  369. interval used during the compression process may also vary for every
  370. frame.
  371.  
  372. Only the interleaved form of YCrCb images is supported for motion
  373. JPEG data. This implies that only one SOS segment will be present in
  374. any particular motion JPEG image.  Following the Tables segment is
  375. the compressed image data. The data is in JPEG stream syntax and
  376. includes the SOI, DRI, DQT, SOF0, SOS, and EOI markers. For
  377. JPEG_YCbCr, JPEG_RGB, and JPEG_Y color space IDs, these markers are 
  378. shown in the typical order with typical values.
  379.  
  380. As with all DIB files and functions that take "packed" DIBs, 
  381. regardless of compression, the offset to the image data can be 
  382. calculated as follows:
  383.  
  384.  
  385.  
  386. ImageOffset = biSize + biColorUsed*sizeof (RGBQUAD)
  387.  
  388. Sample table segment for baseline process:
  389.  
  390.  
  391.  
  392. X'FF', SOI
  393.  
  394.   X'FF', DHT, length, Huffman table parameters (only in still JPEG)
  395.   X'FF', DRI, length, restart interval
  396.   X'FF', DOT,
  397.        length                Lq = 67 for JPEG_Y or
  398.                                   132 for JPEG_RGB or JPEG_YCbCr
  399.        Precision, Table ID,  Pq = 0, Tq = 0
  400.        DQT data [64]
  401.        [If 3 Components
  402.           Precision, Table ID,    Pq = 0, Tq = 1
  403.           DQT data [64]
  404.        ]
  405.   X'FF', SOF0, length,
  406.  
  407.        Sample Precision      P = 8
  408.        Number of lines       Y = biHeight
  409.        Sample per line       X = biWidth
  410.        Number of components  Nc = 1 or 3 (must match information from
  411.          JPEGColorSpaceID)
  412.  
  413.                                           YCbCr     RGB
  414.        1st Component parameters   C1=     1 =Y      4 =R
  415.        2nd Component parameters   C2=     2 =Cb     5 =G
  416.        3rd Component parameters   C3=     3 =Cr     6 =B
  417.        *
  418.        *]
  419.   X'FF', SOS, length,
  420.  
  421.        Number of components  Ns = 1 or 3 (must match information from
  422.          JPEGColorSpaceID)
  423.  
  424.                                           YCbCr     RGB
  425.        1st Component parameters   C1=     1 =Y      4 =R
  426.        2nd Component parameters   C2=     2 =Cb     5 =G
  427.        3rd Component parameters   C3=     3 =Cr     6 =B
  428.        *
  429.        *
  430.        *
  431.  
  432. X'FF', EOI
  433.  
  434. Note that the order in which the internal JPEG data segments 
  435. shown above can actually occur is not restricted by this 
  436. definition; see ISO 10918 for any ordering restrictions that are 
  437. defined.
  438.  
  439. JPEG DIB File Format
  440.  
  441. Support for JPEG under Windows is fast becoming a 
  442. requirement due to the increased number of 16-bit and 24-bit 
  443. adapters on the market. The introduction of JPEG as a 
  444. Windows support file format will allow users to dramatically 
  445. decrease the storage requirement for their 16- and 24-bit 
  446. images.
  447. Every DIB (including JPEG DIB) file has the following format:
  448.  
  449. 1.        DIB file header
  450. 2.        Bitmap information header
  451. 3.        Optional color table
  452. 4.        Image data
  453.  
  454. The DIB file header is defined in the DIB documentation. The 
  455. JPEG DIB bitmap information header is defined in this 
  456. document. The (optional) color table must be RGBQUADs and 
  457. is defined in the DIB documentation. The JPEG DIB image 
  458. data is defined in this document.
  459.  
  460. JPEG AVI File Format
  461.  
  462. JPEG AVI files use the AVI RIFF form as described in the 
  463. Microsoft Multimedia technical note "AVI Files." The JPEG AVI 
  464. file format has the same mandatory LIST chunks as any other 
  465. AVI files. The following example shows the JPEG AVI RIFF 
  466. form expanded with the chunks needed to complete the LIST 
  467. "hdr1" and LIST "movi" chunks:
  468. As defined in the AVI file format, key frames have the key 
  469. frame bit set in the index flags. Since all JPEG frames are key 
  470. frames, this flag will always be set for all the frames in a 
  471. motion JPEG AVI file.
  472.  
  473.  
  474.  
  475. RIFF   ('AVI'
  476.        LIST    ('hdr1'
  477.                'avih'   (<Main AVI header>0
  478.                LIST     ('str1'
  479.                         'strh' (<Stream header>)
  480.                         'strf (<Stream format>)
  481.                         'strd (<additional header data>)
  482.                         .
  483.                         .
  484.                         .
  485.                         )
  486.                LIST     ('movi'
  487.                                {
  488.                                   '##dc' <DIB compressed>
  489.  
  490.                                   Byte abJPEGdata[ ]; <JPEG image data>
  491.                                }
  492.                                .
  493.                                .
  494.                                .
  495.                                <or>
  496.                                LIST ('rec'
  497.                                      '##dc' <DIB compressed>
  498.                                      Byte abJPEGdata [ ]; <JPEG image data>
  499.                                     .
  500.  
  501.                                     .
  502.                                     .
  503.                                )
  504.                         )
  505.                         .
  506.                         .
  507.                         .
  508.                         )
  509.                ['idx' <AVI Index>]
  510.                )
  511.        )
  512.  
  513. The strh chunk contains the stream header chunk that 
  514. describes the type of data the stream contains.
  515. The strf chunk describes the format of the data in the stream. 
  516. For the JPEG AVI case, the information in this chunk is a 
  517. BMINFOHEADER FOR JPEG.
  518. The strd chunk contains the FOURCC ID and associated state 
  519. structure containing any specific state data for initializing the 
  520. identified codec.
  521. All frames in the AVI file are key-frames and have a form 
  522. similar to that defined for JPEG "abbreviated format for 
  523. compressed image data" as specified in ISO 10918 para. B.4.
  524.  
  525. The LIST "movi" Chunk
  526.  
  527. Following the header information is a LIST "movi" chunk that 
  528. contains chunks of the actual data in the streams, that is, the 
  529. pictures and sounds themselves. The data chunks can reside 
  530. directly in the LIST "movi" chunk or they might be grouped into 
  531. "rec" chunks, as described in the AVI file format technical 
  532. note. As in any RIFF chunk, a four-character code is used to 
  533. identify the chunk.
  534. As in the JPEG DIB format, the JPEG stream syntax is used 
  535. for the image data with the following constraints. The JPEG 
  536. marker codes SOI, DRI, DQT, SOF0, SOS, and EOI are 
  537. expected (mandatory) in the image data chunk, and the 
  538. constrained values shown in the example below are mandatory 
  539. for the image data within the AVI stream.
  540.  
  541. Any parameters in the SOF0 (frame) and SOS (start of scan) 
  542. headers that are duplicated in the BITMAPINFOHEADER for 
  543. JPEG must be the same. This would include Sample 
  544. Precision, subsampling, and number of components (as 
  545. implied by JPEGColorSpaceID). The number of lines and 
  546. samples per lines in the SOF0 segment and the width and 
  547. height defined in the format chunk must match the main AVI 
  548. header width and height values. All of these values are 
  549. expected to remain the same for every image data chunk in the 
  550. AVI sequence.
  551.  
  552. Within the image data chunk, two JPEG segments beginning 
  553. with the SOI marker and ending with the EOI marker are 
  554. allowed to accommodate field interleaved streams. There is an 
  555. APP0 marker immediately following the SOI marker that 
  556. contains information about the video image. Specifically, this 
  557. allows the identification of the ODD and EVEN fields of an 
  558. image for images stored in field interleaved fashion. This APP0 
  559. marker is expected to have the first 4 bytes following the length 
  560. bytes set to the characters 'A', 'V', 'I', '1'. The next byte 
  561. indicates which field the JPEG data was compressed from and 
  562. has an expected value of one for the first JPEG data segment 
  563. and two for the second segment, indicating the ODD and 
  564. EVEN fields respectively. If the stream is not field interleaved, 
  565. this value will be 0 and there will only be one JPEG segment. 
  566. The remaining seven bytes are expected to be set to 0 and will 
  567. be ignored by the codec.
  568.  
  569. If a codec cannot handle the interleaved fields, the codec will 
  570. use only the first (ODD) field and will replicate the lines as 
  571. necessary to provide an image that conforms to the image size 
  572. defined in the main AVI header. Conversely, if a capture 
  573. system only accesses a single field of each source frame, only 
  574. a single (ODD) field image may be present in a JPEG stream. 
  575. This implies that the single (ODD) field data should be used as 
  576. the source of both fields by a decompressor that wishes to 
  577. process full interlaced data.
  578.  
  579. It is an advantage to keep the interlace structure of all the 
  580. frames in a particular motion JPEG AVI file consistent. To this 
  581. end, the following convention can be followed concerning the 
  582. relationship of interlace structure to the biHeight parameter of 
  583. each motion JPEG image, and hence the entire AVI sequence.
  584.  
  585. biHeight        Interlace structure suggested
  586.  
  587.  
  588. <= 240        Single JPEG data block describing entire frame.
  589. > 240        A pair of half-height JPEG data blocks describing ODD
  590. and EVEN fields of the frame (EVEN field data is optional if these
  591. blocks would be identical).
  592.  
  593. Note that interlace structure and individual fields of data should be
  594. treated as an internal feature of the image data representation. The
  595. entire frame remains an indivisible unit on which editors etc. should
  596. operate.  The following is an example of what the image data chunk 
  597. would look like for a non-interleaved stream.
  598.  
  599.  
  600.  
  601. X'FF', SOI
  602.    X'FF', APP0' 14, "AVI1", 0, 0, 0, 0, 0, 0, 0, 0
  603.  
  604.    X'FF', DRI, length, restart interval
  605.           length               Lq = 67 for JPEG_Y or
  606.                                     132 for JPEG_YCbCr or JPEG_RGB
  607.           Precision, Table ID, Pq = 0, Tq = 0
  608.           DQT data [64]
  609.           [If 3 components
  610.               Precision, Table ID,  Pq = 0, Tq = 1
  611.               DQT data [64]
  612.           ]
  613.  
  614.    X'FF', SOF0, length,
  615.  
  616.           Sample Precision     P = 8
  617.           Number of lines      Y = biHeight
  618.           Sample per line      X = biWidth
  619.           Number of components Nc = 1 or 3
  620.  
  621.                                              YCbCr    RGB
  622.           1st Component parameters     C1=   1 =Y     4 =R
  623.           2nd Component parameters     C2=   2 =Cb    5 =G
  624.           3rd Component parameters     C3=   3 =Cr    6 =B
  625.  
  626.    X'FF', SOS, length,
  627.           Number of components     Ns = 1 or 3
  628.  
  629.  
  630.                                              YCbCr    RGB
  631.           1st Component parameters     C1=   1 =Y     4 =R
  632.           2nd Component parameters     C2=   2 =Cb    5 =G
  633.           3rd Component parameters     C3=   3 =Cr    6 =B
  634.           *
  635.           *
  636.           *
  637.  
  638.    X'FF', EOI
  639.  
  640. Note that the order in which the internal JPEG data segments (other
  641. than APP0) shown above can actually occur is not restricted by this
  642. definition; see ISO 10918 for any ordering restrictions that are
  643. defined.
  644.  
  645. To identify motion JPEG frames in an AVI "movi'" segment, the stream
  646. ID plus the two-character code for a compressed DIB is used and would
  647. have the following format:
  648.  
  649.  
  650.  
  651.    DIB Bits '##dc'
  652.       BYTE abJPEGImageData [ ];
  653.  
  654. JPEG DIB Definitions
  655.  
  656. The following have been added to MMREG.H:
  657.  
  658.  
  659.  
  660. #define JPEG_DIB     mmioFOURCC('J','P','E','G');
  661.                      /* Still image JPEG DIB biCompression */
  662. #define MJPG_DIB     mmioFOURCC('M','J','P','G'); 
  663.                      /* Motion JPEG DIB biCompression     */
  664.  
  665.     /* JPEGProcess Definitions */
  666. #define JPEG_PROCESS_BASELINE    0    /* Baseline DCT */
  667.  
  668.     /* JIF Marker byte pairs in JPEG Interchange Format sequence */
  669. #define JIFMK_SOF0    0xFFC0   /* SOF Huff  - Baseline DCT*/
  670. #define JIFMK_SOF1    0xFFC1   /* SOF Huff  - Extended sequential DCT*/
  671.  
  672. #define JIFMK_SOF2    0xFFC2   /* SOF Huff  - Progressive DCT*/
  673. #define JIFMK_SOF3    0xFFC3   /* SOF Huff  - Spatial (sequential) lossless*/
  674. #define JIFMK_SOF5    0xFFC5   /* SOF Huff  - Differential sequential DCT*/
  675. #define JIFMK_SOF6    0xFFC6   /* SOF Huff  - Differential progressive DCT*/
  676. #define JIFMK_SOF7    0xFFC7   /* SOF Huff  - Differential spatial*/
  677. #define JIFMK_JPG     0xFFC8   /* SOF Arith - Reserved for JPEG extensions*/
  678. #define JIFMK_SOF9    0xFFC9   /* SOF Arith - Extended sequential DCT*/
  679.  
  680. #define JIFMK_SOF10   0xFFCA   /* SOF Arith - Progressive DCT*/
  681. #define JIFMK_SOF11   0xFFCB   /* SOF Arith - Spatial (sequential) lossless*/
  682. #define JIFMK_SOF13   0xFFCD   /* SOF Arith - Differential sequential DCT*/
  683. #define JIFMK_SOF14   0xFFCE   /* SOF Arith - Differential progressive DCT*/
  684. #define JIFMK_SOF15   0xFFCF   /* SOF Arith - Differential spatial*/
  685. #define JIFMK_DHT     0xFFC4   /* Define Huffman Table(s) */
  686. #define JIFMK_DAC     0xFFCC   /* Define Arithmetic coding conditioning(s) */
  687.  
  688. #define JIFMK_RST0    0xFFD0   /* Restart with modulo 8 count 0 */
  689. #define JIFMK_RST1    0xFFD1   /* Restart with modulo 8 count 1 */
  690. #define JIFMK_RST2    0xFFD2   /* Restart with modulo 8 count 2 */
  691. #define JIFMK_RST3    0xFFD3   /* Restart with modulo 8 count 3 */
  692. #define JIFMK_RST4    0xFFD4   /* Restart with modulo 8 count 4 */
  693. #define JIFMK_RST5    0xFFD5   /* Restart with modulo 8 count 5 */
  694. #define JIFMK_RST6    0xFFD6   /* Restart with modulo 8 count 6 */
  695. #define JIFMK_RST7    0xFFD7   /* Restart with modulo 8 count 7 */
  696.  
  697. #define JIFMK_SOI     0xFFD8   /* Start of Image */
  698. #define JIFMK_EOI     0xFFD9   /* End of Image */
  699. #define JIFMK_SOS     0xFFDA   /* Start of Scan */
  700. #define JIFMK_DQT     0xFFDB   /* Define quantization Table(s) */
  701. #define JIFMK_DNL     0xFFDC   /* Define Number of Lines */
  702. #define JIFMK_DRI     0xFFDD   /* Define Restart Interval */
  703. #define JIFMK_DHP     0xFFDE   /* Define Hierarchical progression */
  704. #define JIFMK_EXP     0xFFDF   /* Expand Reference Component(s) */
  705.  
  706. #define JIFMK_APP0    0xFFE0   /* Application Field 0*/
  707. #define JIFMK_APP1    0xFFE1   /* Application Field 1*/
  708. #define JIFMK_APP2    0xFFE2   /* Application Field 2*/
  709. #define JIFMK_APP3    0xFFE3   /* Application Field 3*/
  710. #define JIFMK_APP4    0xFFE4   /* Application Field 4*/
  711. #define JIFMK_APP5    0xFFE5   /* Application Field 5*/
  712. #define JIFMK_APP6    0xFFE6   /* Application Field 6*/
  713. #define JIFMK_APP7    0xFFE7   /* Application Field 7*/
  714. #define JIFMK_JPG0    0xFFF0   /* Reserved for JPEG extensions */
  715.  
  716. #define JIFMK_JPG1    0xFFF1   /* Reserved for JPEG extensions */
  717. #define JIFMK_JPG2    0xFFF2   /* Reserved for JPEG extensions */
  718. #define JIFMK_JPG3    0xFFF3   /* Reserved for JPEG extensions */
  719. #define JIFMK_JPG4    0xFFF4   /* Reserved for JPEG extensions */
  720. #define JIFMK_JPG5    0xFFF5   /* Reserved for JPEG extensions */
  721. #define JIFMK_JPG6    0xFFF6   /* Reserved for JPEG extensions */
  722. #define JIFMK_JPG7    0xFFF7   /* Reserved for JPEG extensions */
  723. #define JIFMK_JPG8    0xFFF8   /* Reserved for JPEG extensions */
  724.  
  725. #define JIFMK_JPG9    0xFFF9   /* Reserved for JPEG extensions */
  726. #define JIFMK_JPG10   0xFFFA   /* Reserved for JPEG extensions */
  727. #define JIFMK_JPG11   0xFFFB   /* Reserved for JPEG extensions */
  728. #define JIFMK_JPG12   0xFFFC   /* Reserved for JPEG extensions */
  729. #define JIFMK_JPG13   0xFFFD   /* Reserved for JPEG extensions */
  730. #define JIFMK_COM     0xFFFE   /* Comment */
  731. #define JIFMK_TEM     0xFF01   /* for temp private use arith code */
  732. #define JIFMK_RES     0xFF02   /* Reserved */
  733.  
  734. #define JIFMK_00      0xFF00   /* Zero stuffed byte - entropy data */
  735. #define JIFMK_FF      0xFFFF   /* Fill byte */
  736.  
  737. /* JPEGColorSpaceID Definitions */
  738. #define JPEG_Y        1        /* Y only component of YCbCr */
  739. #define JPEG_YCbCr    2        /* YCbCr as define by CCIR 601 */
  740. #define JPEG_RGB      3        /* 3 component RGB */
  741.  
  742. /* Structure definitions */
  743. typedef struct tagEXBMINFOHEADER {
  744.         BITMAPINFOHEADER      bmi;
  745.         /* extended BITMAPINFOHEADER fields */
  746.  
  747.         DWORD   biExtDataOffset;
  748.         /* Other stuff will go here */
  749.  
  750.         /* Format-specific information */
  751.         /* biExtDataOffset points here */
  752. } EXBMINFOHEADER;
  753.  
  754. typedef struct tagJPEGINFOHEADER {
  755.         /* compression-specific fields */
  756.         /* these fields are defined for 'JPEG' and 'MJPG' */
  757.         DWORD   JPEGSize;
  758.         DWORD   JPEGProcess;
  759.  
  760.         /* Process specific fields */
  761.         DWORD   JPEGColorSpaceID;
  762.         DWORD   JPEGBitsPerSample;
  763.  
  764.         DWORD   JPEGHSubSampling;
  765.         DWORD   JPEGVSubSampling;
  766. } JPEGINFOHEADER
  767.  
  768.  
  769. #ifdef MJPGDHTSEG_STORAGE
  770.  
  771. /* Default DHT Segment */
  772.  
  773. MJPGHDTSEG_STORAGE BYTE MJPGDHTSeg[0x1A0] = {
  774.  /* JPEG DHT Segment for YCrCb omitted from MJPG data */
  775.  0xFF,0xC4,0x01,0xA2,
  776.  0x00,0x00,0x01,0x05,0x01,0x01,0x01,0x01,0x01,0x01,0x00,0x00,0x00,0x00,0x00,
  777.  0x00,0x00,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x01,
  778.  0x00,0x03,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,0x00,0x00,0x00,
  779.  
  780.  0x00,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x10,0x00,
  781.  0x02,0x01,0x03,0x03,0x02,0x04,0x03,0x05,0x05,0x04,0x04,0x00,0x00,0x01,0x7D,
  782.  0x01,0x02,0x03,0x00,0x04,0x11,0x05,0x12,0x21,0x31,0x41,0x06,0x13,0x51,0x61,
  783.  0x07,0x22,0x71,0x14,0x32,0x81,0x91,0xA1,0x08,0x23,0x42,0xB1,0xC1,0x15,0x52,
  784.  0xD1,0xF0,0x24,0x33,0x62,0x72,0x82,0x09,0x0A,0x16,0x17,0x18,0x19,0x1A,0x25,
  785.  0x26,0x27,0x28,0x29,0x2A,0x34,0x35,0x36,0x37,0x38,0x39,0x3A,0x43,0x44,0x45,
  786.  0x46,0x47,0x48,0x49,0x4A,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5A,0x63,0x64,
  787.  
  788.  0x65,0x66,0x67,0x68,0x69,0x6A,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7A,0x83,
  789.  0x84,0x85,0x86,0x87,0x88,0x89,0x8A,0x92,0x93,0x94,0x95,0x96,0x97,0x98,0x99,
  790.  0x9A,0xA2,0xA3,0xA4,0xA5,0xA6,0xA7,0xA8,0xA9,0xAA,0xB2,0xB3,0xB4,0xB5,0xB6,
  791.  0xB7,0xB8,0xB9,0xBA,0xC2,0xC3,0xC4,0xC5,0xC6,0xC7,0xC8,0xC9,0xCA,0xD2,0xD3,
  792.  0xD4,0xD5,0xD6,0xD7,0xD8,0xD9,0xDA,0xE1,0xE2,0xE3,0xE4,0xE5,0xE6,0xE7,0xE8,
  793.  0xE9,0xEA,0xF1,0xF2,0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA,0x11,0x00,0x02,
  794.  0x01,0x02,0x04,0x04,0x03,0x04,0x07,0x05,0x04,0x04,0x00,0x01,0x02,0x77,0x00,
  795.  
  796.  0x01,0x02,0x03,0x11,0x04,0x05,0x21,0x31,0x06,0x12,0x41,0x51,0x07,0x61,0x71,
  797.  0x13,0x22,0x32,0x81,0x08,0x14,0x42,0x91,0xA1,0xB1,0xC1,0x09,0x23,0x33,0x52,
  798.  0xF0,0x15,0x62,0x72,0xD1,0x0A,0x16,0x24,0x34,0xE1,0x25,0xF1,0x17,0x18,0x19,
  799.  0x1A,0x26,0x27,0x28,0x29,0x2A,0x35,0x36,0x37,0x38,0x39,0x3A,0x43,0x44,0x45,
  800.  0x46,0x47,0x48,0x49,0x4A,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5A,0x63,0x64,
  801.  0x65,0x66,0x67,0x68,0x69,0x6A,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7A,0x82,
  802.  0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8A,0x92,0x93,0x94,0x95,0x96,0x97,0x98,
  803.  
  804.  0x99,0x9A,0xA2,0xA3,0xA4,0xA5,0xA6,0xA7,0xA8,0xA9,0xAA,0xB2,0xB3,0xB4,0xB5,
  805.  0xB6,0xB7,0xB8,0xB9,0xBA,0xC2,0xC3,0xC4,0xC5,0xC6,0xC7,0xC8,0xC9,0xCA,0xD2,
  806.  0xD3,0xD4,0xD5,0xD6,0xD7,0xD8,0xD9,0xDA,0xE2,0xE3,0xE4,0xE5,0xE6,0xE7,0xE8,
  807.  0xE9,0xEA,0xF2,0xF3,0xF4,0xF5,0xF6,0xF7,0xF8,0xF9,0xFA
  808. };
  809. #endif
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.